Following numerous discussions with various people, I'm opening this PR as a draft for a potential ux-toolkit component. This is the result of a joint reflection with @Kocal and @smnandre .

I’m not speaking on their behalf, but summarizing my interpretation of our discussions. Of course, @Kocal and @smnandre, feel free to correct, adjust, or add anything as needed.

Why?

Saving time

Creating Twig components like Badge or Button seems to be a very common step. The same work appears to be done over and over again, with minor differences from one company to another.

Providing a "packaged" toolkit would allow these companies and developers to save time by starting from ready-made templates.

Simplifying the process

Today, a beginner coming to Symfony has a lot to learn. Onboarding on a Symfony project can feel overwhelming, so it makes sense to offer them the most pleasant experience possible—including making it as easy as possible to create a clean and visually appealing web page.

Improving quality and accessibility

By providing a toolkit, we can leverage an entire community to gradually enhance the quality of components, including their digital accessibility. Accessibility is a major challenge, and we can aim to provide components that help companies and developers better support it.

How?

By providing:

• Boilerplate for basic, accessible components (button, badge, etc.)
• A symfony console ux:toolkit:install Button command that will generate the corresponding Twig component in the user's project. If necessary, this command will also install any required dependencies (if a component relies on another one).

Components will be unique.

It will be possible for the community to distribute unofficial components: for example, the command could accept symfony console ux:toolkit:install github.com/MyRemote/UiKit:Button

The website https://ux.symfony.com/ will include:

• Presentations of each component, with a demo and the code needed to use it.
• Options for automatic installation (via the command) or manual installation (by copying and pasting Twig code).
• A few demos showcasing different variants.

Philosophy

Since the web is constantly evolving, it would be difficult to commit to maintaining components that require frequent updates.

An approach similar to shadcdn seems more suitable: components are generated locally on demand by the developer, who will handle updates if necessary.

This approach likely offers the greatest flexibility: the developer can customize their component as they see fit, add their own variants, and adapt it to their specific needs.

The list of components could be based on the OpenUI initiative, which already provides a solid selection.

The symfony/ux-toolkit package will not be responsible for installing the CSS required for the components to function. It remains the developer's responsibility to manage their assets.

Next steps

There’s still a lot of work to do, which @Kocal will outline shortly. But it would be great to get feedback on the approach.

There is a lot of work to do; if the project is approved and the chosen direction is satisfactory, it would be great to create high-quality components. Looking forward to your feedback!

UX is an amazing component - it just needs "that little extra something" to truly make a difference in the daily lives of Symfony developers. I hope this kind of feature can help achieve that.

Takslist

• Initialize symfony/ux-toolkit boilerplate
• Create configuration tree:

ux_toolkit:
    # Either `default` or `new-york`, like https://ui.shadcn.com/ themes
    theme: default

    # Similar to https://symfony.com/bundles/ux-twig-component/current/index.html#configuration
    prefix: null

• Do not hard depend on https://github.com/tales-from-a-dev/twig-tailwind-extra, but dev dependency, and document that the user needs to install tales-from-a-dev/twig-tailwind-extra if it wants to fully use our components
• Implement ux:toolkit:install command
  • Handle local components (i.e.: ux:toolkit:install Button)
  • Handle remote components (i.e.: ux:toolkit:install github.com/MyRemote/UiKit:Button)
  • The command must use the Registry system (see below)
  • Support dependencies across components
  • Check if component's files already exist before writing, and ask to the user its choice
  • We must take the user's prefix when installing components, e.g.: <twig:Badge> must be replaced by <twig:Foobar:Badge> if the user use the prefix Foobar
• The Registry system
  • It's a bunch of .json containing the list of components, their name, type (component or example/variant), registry dependencies, source code, ... that will be used by the ux:toolkit:install command and the ux.symfony.com website:

➜  Toolkit git:(ux_toolkit) tree registry 
registry
└── default
    ├── components
    │   ├── Alert.json
    │   ├── Badge.json
    │   ├── Button.json
    │   ├── Card.json
    │   ├── Navbar.json
    │   ├── Table
    │   │   └── Row.json
    │   └── Table.json
    └── examples
        ├── Badge.json
        ├── BadgeOutline.json
        └── Button.json

# default/components/Button.json
{
    "name": "Button",
    "theme": "default",
    "type": "component",
    "code": "<button {{ attributes.without('class') }}\n    class=\"{{ (' ' ~ attributes.render('class'))|tailwind_merge }}\"\n>\n    {% block content %}Button{% endblock %}\n<\/button>\n",
    "dependencies": []
}

# default/components/Button.json
{
    "name": "Table",
    "theme": "default",
    "type": "component",
    "code": "{# ux:with{Row, Button} #}\n<table {{ attributes.without('class') }}\n    class=\"{{ (' ' ~ attributes.render('class'))|tailwind_merge }}\"\n>\n    {% block content %}{% endblock %}\n<\/table>\n",
    "dependencies": [
        "Row"
    ]
}

• For the Registry
  • Architecture Registry and RegistryItem
  • Provide a PHP script that build this Registry
  • The Registry must be able to read and handle components
  • The Registry must be able to read and handle examples
• Implement components:
  • List, based on https://ui.shadcn.com/docs(and https://open-ui.org/)
    • Button
    • Badge
    • Avatar
    • ... to complete
  • Components must use html_cva, to provide a good development and customization experience for UX maintainers and users
  • Components must stay customizable from the outside, by passing the class property, by using the following boilerplate: <div class="{{ style.apply({}, attributes.render('class'))|tailwind_merge }}" {{ attributes.defaults({}).without('class') }}>
  • Add many examples/variations of components
• Add a new page on ux.symfony.com
  • Some documentation about the Toolkit's philosophy, ...
  • Document about tales-from-a-dev/twig-tailwind-extra non hard-requirement, and what it can provides to users
  • Document how users can create their own toolkit (put symfony/ux-toolkit in dev dependency, run ./vendor/symfony/ux-toolkit/bin/generate-registry.php, ...)
  • Based on the Registry system
  • One page per component
    • Show automatic or manual installation steps
    • Show a demo and source code of the component
    • Show examples/variants